In conventional transaction processing systems, transaction requests are processed on general-purpose processing hardware that executes software or firmware. Each transaction request may include multiple, sequential subtasks that must be completed sequentially to process the task as a whole. These subtasks in turn include discrete operational elements, such as compute or memory access functions. As each task is received, the conventional transaction processing system processes each subtask sequentially by performing the operations instructed by the first subtask, then the second, and so on. These operations may include reading or writing data, storing or loading operands, performing logical computations, manipulating data structures, or branching to a different set of instructions altogether. In most inefficient architectures, the transaction processor is fully dedicated to a given transaction request, therefore the subtasks of each transaction request are completed in sequence regardless of processor idle time. Some transaction processors may begin to process the next transaction request while waiting for results from the current transaction request subtask. For example, the current transaction request subtask may include an external device read instruction. After the processor makes the read request using the correct protocol, it waits for the requested read data to arrive. While the processor is waiting, it is free to begin the processing of a subtask from a different transaction request. This involves the processor storing current data, state information, and status to memory then loading the new subtask instructions into its registers. The processor begins to process the new subtask until the data arrives from the previous subtask request. At that point, the processor can proceed to the next subtask of the original transaction request. The ability to switch between subtasks of different transaction requests allows a more efficient use of processor cycles; however, the sequential nature of the task processing fundamentally limits throughput.
With the explosive growth of the use of digital data and networking, the numbers of transactions that transaction processing systems are required to handle per unit of time has significantly increased. This growth has outpaced the advances in processor speeds, such that the performance of conventional transaction processing does not meet the market demand. As transaction volumes increase, the traditional model of sequential processing, even with the ability to swap subtasks while waiting for results, is increasingly becoming a limiting process. One solution has been to provide a transaction processing system with more than one processor. However, each processor still requires overhead to swap the tasks or subtasks to which it is assigned. This technique does not relieve the need for additional overhead consumed by subtask swapping. Subtasks must usually be processed sequentially in order to maintain the integrity of the overall task. Parallel processing of subtasks may mean that subtasks are processed out of order. Therefore, typical parallel processing must use additional overhead to ensure orderly completion of subtasks.
U.S. Pat. No. 6,219,689, entitled, “Parallel transaction processing system,” describes a parallel transaction processing system that performs efficient parallel processing of multiple tasks and includes a queue for storing a plurality of transaction data that can be processed independently, a control table containing control information for the queue, and a means for operating a plurality of tasks that performs the same processing on the transaction data stored in the queue. A corresponding parallel transaction processing method includes the steps of: storing a plurality of transaction data in a queue that can be processed independently, providing a control table containing control information for the queue, and operating a plurality of tasks that perform the same processing on the transaction data stored in the queue. Each of the operated tasks reserves a predetermined number of consecutive transaction data for processing among unprocessed transaction data stored in the queue by referencing the control table, writes its reservation status in the control table and, upon having processed the reserved transaction data, writes its processing status in the control table.
Although the system described in patent '689 provides a method for parallel processing of multiple tasks, it fails to provide a method for processing the subtasks in order without unacceptable overhead. The system described in patent '689 also fails to provide a scalable architecture that can be easily expanded when more processing power is needed. It also is not flexible enough to be incorporated into systems with different transaction types.
Therefore, it is an object of the present invention to provide significantly increased performance in a transaction processor system. It is another object of this invention to enable more complex transactions in the same amount of processing time. It is yet another object of this invention to provide a scalable transaction processor architecture that can be leveraged across many different transaction types and speeds. It is yet another object of this invention to make swapping process control between subtasks more efficient. It is yet another object of this invention to provide a method that manages process control in such a way that maintains transaction integrity.